.nr Hc 2
.nr Hs 9
.nr Hb 9
.nr Ej 0
.nr Pt 0
.rm ul
.rm cu
.TL
PROPOSED REVISIONS TO MIL-STD-1778

(Transmission Control Protocol)
.AF "FACC / Palo Alto"
.AU "John Nagle" JBN "" "Software Technology"
.PF "'Draft 1.7'PROPOSED REVISIONS TO TCP'3/26/84'"
.MT 4
.SA 1
.H 1 "INTRODUCTION"
The present TCP standard (MIL-STD-1778 of 12 August 1983), while
valuable, is not tightly enough drawn to allow implementors to simply
implement to standard and be assured of a satisfactory TCP.
It is proposed to tighten up the TCP standard to
the point that if two implementations comply with the standard, the
implementations will be able to communicate efficiently.
The object is make TCP a ``plug it in and turn it on'' protocol from
the user's standpoint.
.P
This document begins the process of constructing a revised MIL-STD-1778.
Comments should be sent to Internet mail address XXXX@XXXX.
All references here are to MIL-STD-1778 of 12 August 1983.
.H 1 "GENERAL GOALS"
TCP was developed in the ARPA community as an experimental protocol.
One of the primary criteria used in drafting the original standard
was to allow maximum flexibility for the implementors.
Sufficient operational experience has now been acquired to allow
identification of specific problems with the present standard of
the protocol.  The present standard is not sufficient to insure
efficient interoperability.  This is a serious obstacle to the use of
TCP in deployable DoD systems.  The time has thus come to turn from
allowing maximum flexibility to insuring maximum interoperability.
.P
The revised standard will be more restrictive than the old
standard.  All implementations compliant with the new standard
should be compliant with the old, but old implementations may need
updating to comply fully with the new standard.  This updating
should not require substantial changes to the implementation.
.P
It is also desirable that compliance with the standard be
verifiable by external testing, as is the case for ISO X.25.  While
TCP has many more states than X.25 (primarily because the sequence
space is much larger) and true exhaustive testing is thus not
possible, as it is for X.25 with about 3000 test messages, it is
desirable that the behavior of the implementation be somewhat
predictable in various situations so that testing against scripts is
possible.
.P
TCP implementations must be well-behaved when used over
datagram
networks with only advisory flow control.  The correct operation of
pure datagram networks under heavy load requires that the transport
layer not saturate the network with unnecessary traffic, and in
particular that the transport layer not increase its traffic
generation in response to network delays.
In particular, the case of high-speed local networks interconnected
by slower long-haul networks must be well-handled.
.H 1 "ENVIRONMENT OF TCP"
TCP is designed for use in DoD military data communications systems.
As such, it is required to be an exceedingly robust protocol and
may be called upon to operate in environments more severe than normally
expected in commercial data communications.
.P
The underlying network over which TCP segments are transmitted may have
a wide range of properties, but this range is constrained to have the
limits given here.  These limits are necessary to allow engineering
decisions necessary for interoperability.  It is intended that the
standard will assure proper operation over networks with the
properties given below.  Use of TCP for networks with strongly
different properties falls outside the scope of the TCP standard.
.P
The numbers given here reflect our own judgement; we request DCA guidance
in this area.
.BL
.LI
TCP is expected to operate over transmission paths with bandwidths from 1200
to 100,000,000 baud.  With bandwidths below 1200 baud, round-trip times may
become excessive and operation may be infeasible.  There is as yet
insufficient experience with very high bandwidth operations to assure
operation above 100Mb; however, IP/TCP operations over 50Mb links have
been successfully demonstrated.
.LI
A TCP implementation cannot make any assumptions about the lower limit
of bandwidth available between itself and the remote TCP.
The fact that a TCP happens to be attached to a high-bandwidth device
locally does not imply that the path to the remote TCP does not contain
some low-bandwidth sections.
.LI
Propagation delays may vary from zero to two minutes in extreme cases.
Proper operation is required whenever the mean delay is less than 15 seconds.
.LI
TCP segments may be lost, interchanged, duplicated, corrupted,
or delayed in transit up to two minutes.
Proper operation is required despite occurences of the above events,
provided that the rate of occurence is ``moderate''.
The definition of ``moderate'' is open to discussion.  It is desirable to
use a specific number in the standard.  A 5% segment loss rate, however, should
be considered within the moderate range.  It may be feasible to allow higher
error rates.  While these rates are far higher than those typically encountered
in commercial packet networks, allowance should be made for
the use of TCP in deployed military systems.  DCA guidance is desirable here.
.LE
.H 1 "SPECIFIC ITEMS"
Based on our experience with TCP interoperability testing, we
have identified a
number of specific problems with the present standard.  We describe
these below and propose solutions.
Overall, it appears that TCP implementations will become smaller, simpler,
and faster as a result of these changes.
.H 2 "RETRANSMISSION TIMERS"
.H 3 "Issues"
The present standard does not give specific numbers controlling
the behavior of the retransmission timer.  It is proposed to specify
such numbers.
The initial value must be great enough to prevent excessive initial
transmissions on slow links, and must back off to an upper limit high
enough to prevent congestion collapse.
.H 3 "Proposed changes"
.BL
.LI
The initial value should be >= 1 sec and <= 3 sec.
.LI
The upper limit should be >= 15 sec and <= 1 minute.
.LI
RTT must be computed by some suitable algorithm and
retransmission timeouts must be >= 2*RTT.
.LE
.H 2 "OUT OF ORDER SEGMENT HANDLING"
.H 3 "Issues"
The present standard allows either ``in window'' or ``in order''
data acceptance.  Operational experience indicates
that ``in window'' data acceptance is preferred especially in the
presence of network errors.
Further, ``first only'' retransmission is known to be superior when
``in window'' data acceptance is being used, and also has the desirable
property of minimizing unnecessary traffic.
``Batch'' retransmission is known to be inferior to the other
strategies and present advice to implementors suggests that it not be used.
.H 3 "Proposed changes"
Revise 9.2.4.1 to specify ``in window'' data acceptance.
Revise 9.2.5.4 to specify ``first-only'' or ``individual'' retransmission,
deleting the option of ``batch'' retransmission.
The possibility of specifying a single retransmission algorithm should be
discussed.
.H 2 "SIZE OF DATAGRAMS / TCP OPTIONS"
.H 3 "Issues"
At present the concept of TCP options exists only in the prose description.
Also,
9.3.11.1.3 states that any segment size is allowed in the absence of
a maximum segment size option.
Clarification is required.
.H 3 "Proposed changes"
A field sv.send_maxsize should be inserted into the data structure and
updated when a maximum segment size option is received.
Its initial value is defined as default_max_segment_size (a constant)
and this value should be chosen to keep the datagram size at 576 for
TCP implementations used on top of IP.
.P
It should be made clear that the default
segment size results in 576 byte IP datagrams.
.P
All implementations must be able to accept datagrams of this
size, and options are used only to inform the other end that larger datagrams
are acceptable.
This is consistent with most present implementations
and allows ignoring the maximum size option when larger packets are not
supported.
.P
There is only one defined option, and it can appear only in the SYN segment.
It is proposed to prohibit future options in non-SYN segments, and
prohibit data in the SYN segment if options are present; this
will allow slightly faster implementations because the data portion of
a segment will always be in a fixed place.
.H 2 "CONGESTION CONTROL"
.H 3 "Issues"
Small packet congestion must be prevented and unnecessary ACK traffic
eliminated.
These issues are discussed more thoroughly in RFC896, ``Congestion
Control in IP/TCP Internetworks''.
.H 3 "Proposed changes"
The solution proposed here is a generalization of the one described
in RFC896.
The proposed solution restricts the freedom of the implementor but
eliminates the small-packet problem, the need for a PAD timer,
the need for repacketization on retransmission, the need for
delaying acknowledges, and any possibility of
silly window syndrome.  The new solution handles all of these problems
in the formal TCP entity standard, without recourse to prose advice.
.P
It is proposed that send_policy
(ref 9.4.6.3.43)
behave as follows:
.DS
                                        -- compute amount sendable now
        size = min(data_avail, min(sv.send_wndw, sv.send_cwndw));
        if (sv.snd_nxt = sv.snd_una)    -- if connection is idle
        then send_policy := size;       -- send everything we can
        else                            -- if unacked data is outstanding
                if (size < default_max_segment_size) -- if < 576-40
                then send_policy := 0;  -- don't send now, too small
                else                    -- enough to consider sending
                                        -- limit size per other end's max
                        size := min(sv.send_maxsize,size);
                        if (size = sv.send_maxsize) -- if largest possible
                        then send_policy := size; -- send it now
                        else            -- above default but below max
                                -- use send policy for very large segments
				if (send_policy_2()) -- if policy says yes
                                then send_policy := size; -- send it now
				else send_policy := 0; -- wait for more
.DE
.P
Note that sv.send_cwndw and sv.send_maxsize are new fields, introduced
in the sections on CONGESTION ADVICE and SIZE OF DATAGRAMS respectively.
The constant default_max_segment_size was introduced in SIZE OF DATAGRAMS.
The variable data_avail reflects the number of bytes of new data now
available for sending.
The new function send_policy_2 allows implementors to control the send
policy used when sending very large segments (above the default maximum).
This function should return TRUE if the implementor desires to send
or FALSE if the implementor desires to defer sending until more data
is available for transmission.
.P
This send policy has the following properties:
.AL
.LI
All data will eventually be sent, with or without a PUSH.
.LI
When data to be sent is being generated in small bursts, as from a
keyboard, in the absence of errors, any data item
will be sent within two round trip times.
.LI
When data to be sent is being generated rapidly, maximum sized segments
will be sent.
.LI
When sending into a nonempty window, no packet smaller than
default_max_segment_size will ever be sent.  This eliminates any
possibility of silly window syndrome.
.LI
Windows of any size will work, although if the remote implementation always
offers a window smaller than default_max_segment_size TCP becomes a
stop-and-wait protocol.  Implementations should not normally offer such
small windows unless under severe resource pressure; however, proper
operation will continue under such constraints.
.LI
No more than one packet smaller than the default_max_segment_size
will be outstanding at any time.  This eliminates the problem of
gateway congestion due to large numbers of tiny packets introduced
by virtual terminal operations.
.LI
Implementors using very large windows and/or packets have the freedom to
affect the policy used when the data to be sent is larger than the
default_max_segment_size but smaller than the size negotiated with the
TCP maximum segment size option.  In this case the implementor may choose
to send and maximize response or wait and achieve maximum throughput.
However, the behavior of send_policy_2 will not affect the correctness of
the operation.
This option is provided primarily for wideband network experimentation.
.LI
Congestion handling is incorporated into the policy.  See ``CONGESTION ADVICE''
below.
.LE
.H 2 "WINDOW MANAGEMENT POLICY"
.H 3 "Issues"
This should be built into the state tables, rather than being described
only in the prose.
.H 3 "Proposed changes"
The send_policy above handles silly window syndrome.
Further, given the large packets forced by the new send_policy, there
is little need for deferring window updates.  Section 9.2.3.4
can thus be eliminated.
.H 2 "ZERO WINDOW PROBING"
.H 3 "Issues"
The one-byte probe of the zero window is presently described in 9.2.3.1 but
the state tables do not reflect this feature.
.H 3 "Proposed changes"
The state tables need to be updated.  This is a non-trivial change, and
reflects a serious omission in the present standard.  It will be difficult
to correct this change without introducing errors in the standard.
.H 2 "CONGESTION ADVICE"
.H 3 "Issues"
TCP must be informed of advisory congestion information returned from
the datagram level, such as ICMP Source Quench messages,
and must act on them by reducing the amount of outstanding data
on the connection.
.H 3 "Proposed changes"
Add the concept of a ``congestion window'' state variable sv.send_cwndw.
The congestion window is used by the send policy to limit the amount of
outstanding data on the connection.
Receipt of a quench sets sv.send_cwndw to 50-90% of sv.send_nxt - sv.send_una,
thus setting the congestion window to somewhat under the amount of data
currently outstanding.  Each ACK which advances the window increases
sv.send_cwndw by 5-20%, so that the window slowly grows over time
unless quenched.
The sv.send_cwndw may never be smaller than the default maximum segment size and
may never exceed 65535.
The congestion window thus is maintained at just under the amount of data
on the connection at which congestion is observed.
.P
The initial value for the congestion window should be between
2 and 5 times the default_max_segment_size.
This is significant only for TCP implementations which use very large
windows; such implementations can impose a large transient load when
attempting to begin a large data transfer over a path containing
gateways with small buffers.  It is thus desirable to
start up very large transfers slowly, thus reducing the starting
transient and providing an opportunity for advisory
congestion information to reach the sending TCP.
.P
Some flexibility is offered implementors in adjustment of the parameters of
the algorithm but the algorithm is to be mandatory.
.H 2 "PUSH"
.H 3 "Issues"
The PSH bit is a relic of an earlier line-oriented form of TCP.
It was originally called the ``EOL'' bit, for End Of Line.
It is no longer significant in most modern implementations.
.H 3 "Proposed changes"
.BL
.LI
The PSH bit should be ignored when found in received segments; all
segments should be delivered to the user whether or not the PSH bit
appears.  All references to pushed data should be eliminated from
the TCP receive entity specification.
.LI
The PSH bit should be set in transmitted segments when the segment
being sent contains the last data available to be sent at this time.
.LI
The PUSH_FLAG argument should be deleted from the Send event.
.LE
.P
With these rules, old implementations will continue to work and new
implementations will be simplified.
.H 2 "REUSE OF CONNECTIONS"
.H 3 "Issues"
Section 9.2.13.3 states that ``TCP imposes no restriction on a particular
connection
being used over and over again,'' but at present the reuse of connections
either requires delays between reuse or seems unsafe.
Either immediate reuse should be made safe or immediate reuse should be
explicitly prohibited.
It needs to be made more clear that the ``quiet time concept'' applies
only to reinitializations of the TCP implementation in which sequence
information has been lost.
.H 3 "Proposed changes"
.BL
.LI
A connection closed without going through the full close handshake
(i.e. aborted before reaching the TIMEWAIT state)
cannot be reused for 2*MSL.
.LI
A new OPEN is to be permitted when a connection is in TIMEWAIT.  Such an
open would save the sequence number of the old connection, close the
old connection, and open the new connection with a sequence number
generated by adding a suitable number (65537, the maximum window size
plus one, is suitable) to the final sequence number
of the old connection.
This guarantees a disjoint sequence space for the new connection.
.LE
.P
The above appears to be sound, but needs to be carefully examined.
Duplicate datagrams received once the new connection is in a synchronized
state are clearly harmless.  There could be trouble if an old duplicate
SYN appeared in SYN-RECEIVED or SYN-SENT state, but the mechanism described in
section 9.2.13.2.2.2 handles this.  This seems to cover everything.
The restriction on reuse of aborted connections prevents old RST segments
from causing trouble.
This particular proposal needs to be carefully examined for soundness.
.H 2 "INCORRECT TABLE IN SPECIFICATION"
.H 3 "Issues"
In the original printing, table XII and table XIV were interchanged.
Incorrect copies may be identified by the absence of a column
headed ``ZERO RCV WINDOW'' in table XII, ``Net deliver event in an
estab state.''
.H 3 "Proposed solution"
This problem was corrected in a later printing.
.H 2 "SEQUENCE NUMBER ARITHMETIC"
.H 3 "Issues"
Sequence numbers are expressed strictly in modular arithmetic,
defined here as unsigned modular arithmetic in the space 0..2**31-1.
However, there are places in the TCP entity standard where
there are inequalities between two variables of sequence_number_type.
(See 9.4.6.2.2, ``ACK status test 1'', for example).
This is formally incorrect; the concept ``A > B'' is not meaningful
for variables in modular arithmetic.  This may lead to incorrect operation
of implementations when special cases arise near the edges of the
sequence number range.
The present standard mentions but does not properly address
this issue in section 9.2.2.1.1.
.H 3 "Proposed solution"
The proper way to perform the comparisons
is by using a ``within'' primitive, defined
by
.DS
        within(val,low,high) =
                   (low <= high and low <= val and val <= high)
                or (low >= high and low >= val and val >= high)
.DE
.P
``within'' is then true if and only if ``val'' is between ``low'' and ``high''.
Most existing implementations actually use such a primitive.
All comparisons between variables of type sequence_number_type should
be performed using ``within''.
.P
A less satisfactory approach is to define ``<'' and ``>'' to have an
arbitrary meaning for modular arithmetic; if this is done, care must
be taken with the definition; in general, the definition should
preserve trichotomy (exactly one of a<b, a=b, and a>b may be true)
although of course transitivity cannot be preserved.
.P
This problem should be returned to the authors of the existing standard
for correction.
.H 1 "CONCLUSION"
The changes proposed here begin the process of tightening up the TCP
standard to the point that users can expect interoperability when
correct implementations try to intercommunicate.  We encourage readers
to look hard for errors in this paper; we want an correct standard.



